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DESIGN SYSTEM UPGRADE MIGRATION 

FIELD OF THE INVENTION 
This invention relates to upgrading design 
systems comprising tools that permit users to design 
5 application-specific integrated circuits (ASICs) 
using vendor technology, and particularly to 
migration of user scripts and files through revisions 
and upgrades of vendor design systems. 

BACKGROUND OF THE INVENTION 

10 ASICs are manufactured by ASIC vendors 

using vendor-proprietary semiconductor technology. 
The ASIC vendor often supplies its customers with an 
"ASIC design system" that includes a suite of tools, 
ASIC vendor data and methodologies/flows. The ASIC 

15 design system permits the customer to design 
integrated circuits (ICs) which, when fabricated 
using the ASIC vendor's technology, implements a 
functional design of the user. The ASIC design 
system includes a large number of model sets and 

20 associated procedures that enable the customer to 
employ widely available Electronic Design Automation 
(EDA) tools using the ASIC vendor's technology. Due 
to the large number and types of circuits that 
comprise an ASIC vendor' s technology, the technology 

25 is ordinarily cataloged into functional groups, 
called "libraries". For example, a vendor may 
provide a Small Computer System Interface (SCSI) 
circuit library so customers can implement designs 
that conform to the SCSI input/output (I/O) standard. 
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The model sets that represent these 
technology libraries vary widely in format. Some 
model sets are text-based formats, some are binary, 
some include multi-circuit libraries, yet others 
5 represent single circuit models. These libraries are 
usually represented by a large number of directories 
that organize related files into groups. The 
directories represent the ASIC vendor's technology 
library groupings . Each directory contains a source 

10 name. The number of these directories, and the names 
assigned to each directory, are based on the ASIC 
vendor's technology library groupings. These 
directories are necessary due to the large amount of 
data that must be represented and the architecture of 

15 modern EDA tools that the design system must support. 

Moreover, for increased design flexibility, 
it is beneficial to the customer that an ASIC vendor 
support as wide array of EDA tools as practical. As 
the number of EDA tools increases, the number of 

20 libraries, and the complexity of the associated 
directories, multiplies . 

The high complexity of modern design tools, 
together with an increasingly complicated design 
system directory structure, require customers to 

25 frequently document design efforts by creating 
wrapper scripts and configuration files. Wrapper 
script and configuration files define the ASIC 
netlist and parameters in an executable log file that 
references file paths in the applicable ASIC design 
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system. The netlists are technology dependent; that 
is, they represent the ASIC in terms of a specific 
technology system associated with an ASIC vendor. 
These scripts and files often make multiple 
5 references to various subdirectories and file paths 
within the library directory structure. 

As ASIC vendors continue to develop and 
improve ASIC design systems, the need arises to 
change the file groupings and/or directory structure 
10 in order to implement new features or changes to the 
C3 overall system. Changed groupings and file paths 

•|i cause problems for existing users who have invested 

considerable effort into the creation of wrapper 

yj scripts and configuration files that reference file 

in 

15 paths in the ASIC design system. These changes also 
s create problems for the ASIC vendor because 

y information concerning the changes often needs to be 

J'** explicitly communicated to customers to guide them 

p through the process of updating these embedded 

r 20 library references. 

Currently, ASIC vendors introduce changes 
to ASIC design systems in either (or both) of two 
approaches. First, vendors might document the 

changes and assist customers in adjusting their 
25 environments manually. This approach requires the 
ASIC vendor to carefully document the changes, and it 
imposes an additional burden on the ASIC vendor's 
support staff to assist customers who did not read or 
understand the documentation. Moreover, 



-4- 



documentation and manual adjustment to accommodate 
changes in the ASIC design system tends to be error- 
prone and time-consuming since the customer is forced 
to do updates manually based on documentation 
5 information. 

A second approach for ASIC vendors is to 
make no changes to existing versions of the design 
system, but instead to introduce new versions of ASIC 
design systems as new releases. This approach 

10 suffers loss of flexibility, and creates an 
impediment on the ASIC vendor development team from 
making and implementing changes to library contents 
and from regrouping functional blocks as the 
technology offerings mature. Moreover, as the design 

15 system matures, new features are assigned to existing 
groups, rendering the library contents less logically 
grouped in subsequent versions . Consequently, later 
versions of the design system become more difficult 
for customers to use. More particularly, customers 

20 experience greater difficulty finding specific files 
and taking advantage of new offerings in subsequent 
releases of the design system. 

SUMMARY OF THE INVENTION 
In one embodiment of the invention, a 

25 software tool is created to migrate computer files 
that define ICs from older to newer computer-readable 
directory structures. The old and new directories 
are compared to identify differences. A computer- 
readable map file is generated containing a plurality 
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of lines, with each line referencing a difference 
between the old and new directory structures. The 
lines are sorted into an ordered list based on source 
name. A computer-readable code, representing a 
5 modification between the old and new directory 
structures, is generated for each source name. The 
tool is generated based on the computer-readable 
codes, and is useable to migrate computer files from 
the old to the new directory structure. 
10 In preferred embodiments, the tool script 

is packaged with the new computer-readable directory 
structure . 

In another embodiment of the invention, the 
tool is used to migrate a computer file that defines 

15 an IC in the old directory structure to one that 
defines the IC in the new directory structure. The 
computer file is input to a computer containing the 
tool. The computer identifies source names that are 
referenced by the tool and appear in lines of the 

20 computer file. For each identified source name, the 
associated directory reference is changed from the old 
to the new directory structure. 

In preferred embodiments, the lines 
containing a changed directory reference are stored to 

25 a second computer file . The second computer file is 
output as defining the IC in the new directory 
structure. 

Another embodiment of the invention is a 
computer software tool that operates a computer to 
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migrate a user's computer file defining an IC from an 
old to a new directory structure. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIGS . 1 and 2 are flow charts of a process 
5 for developing a tool, according to an embodiment of 
the present invention, which is useful to migrate 
user scripts and files through revisions and upgrades 
of IC design systems. 

FIGS. 3A and 3B, taken together, is a flow 
10 chart of a migration process performed by the tool 
developed by the process of FIGS. 1 and 2 according 
to an embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present invention is directed to 
15 techniques that aid in the migration of user scripts 
and configuration files to new revisions of the 
design system. The invention provides a tool that 
supports system updates and provides the framework to 
support future system updates. 
20 ASIC customers define integrated circuits 

as wrapper script and configuration files that define 
the ASIC netlist and parameters that are technology 
dependent; that is, they represent the ASIC in terms 
of a specific technology system associated with an 
25 ASIC vendor. The specific ASIC design is often 
proprietary to the customer, whereas the specific 
technology system is usually proprietary to the 
vendor. The netlist is employed by the ASIC vendor 
to fabricate (manufacture) the ASIC chips for 
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integration by the customer into a customer product. 
For example, the ASIC chip may be a customer- 
proprietary processor to be mounted on a circuit 
board as part of the customer's end product. 
5 ASIC vendors often improve the technology 

system, resulting in improvements to the design 
system. ASIC customers often desire to take 

advantage of advances in the vendor's technology by 
upgrading, and hence improving, the customer's chip 
10 to incorporate new features in the vendor technology 
£9 system. Moreover, as customer chip complexity 

y§ increases, the chip design is exposed to new vendor 

^ technology and design system changes. To incorporate 

v3 vendor technology into the customer chips, the 

|| 15 customer's wrapper script and configuration files 

e must be modified for compatibility to the modified 

y technology system. Advanced netlists are generated 

from the modified wrapper script and configuration 
Q files for use by the ASIC vendor in fabricating the 

^" 2 0 advanced ASIC chips. 

FIG. 1 is a flow chart illustrating steps 
performed by the ASIC vendor to generate a mapping 
file describing changes between revisions or releases 
of the vendor's IC design system. FIG. 2 is a flow 
25 chart illustrating steps performed by the ASIC vendor 
to develop a software tool that is useful to the 
users of the vendor's IC design system to migrate 
user script and files from the original to a new 
version or release of the IC design system. FIGS. 3A 
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and 3B, when edge matched, is a flow chart 
illustrating the steps performed by the software tool 
under control of the user to migrate the user's 
script and files. 
5 FIG. 1 illustrates the process performed by 

a computer to generate a mapping file that identifies 
differences between a previous directory structure 
and a current directory structure- Directory 
structures 100 and 102 are sequential versions or 

10 releases of the same ASIC design system. For 
example, the existing or previous directory structure 
of the ASIC design system might be version 2.0, 
whereas the new directory structure might be version 
3.0 of the same ASIC design system. At steps 100 and 

15 102, the computer readable version of the previous or 
existing directory structure and the computer 
readable version of the new directory structure are 
input to the computer. At step 104, the computer 
compares the two directory structures, and at step 

20 106 the computer provides a line-by-line output 
identifying the differences between the two 
directories in old/new format. At step 108, the 
computer generates a computer readable mapping file. 
The mapping file includes a list of differences, with 

25 each item or map of the list referencing the 
applicable source name. The process of FIG. 1 is 
ordinarily performed using the same computer system 
as the ASIC design system. For example, the steps of 
FIG. 1 may be accomplished using a UNIX tool set. 
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The migration tool of the present invention 
is developed using the process illustrated in FIG. 2. 
Starting at step 200 where the mapping file created 
at step 108 is read, at step 202 the maps are sorted 
5 based on selected criteria. For example, in one 
preferred embodiment the items or maps are first 
sorted by the length of the source name referenced by 
the item or map, and second by alphanumeric order 
(such as alphabetic) of the source names of equal 
10 length. 

At step 204 , an iterative process is 
performed on each item or map of the sorted list. 
More particularly, for each line, at step 106 the 
directory name is parsed, and a new string, written 

15 in Perl, is created at step 108 having a modification 
syntax " S/OLD/NEW/g" . The result identifies a 

relationship for the respective line item or map that 
represents a modification between the two input 
directory structures associated with the source 

20 names. The result is output to the tool script at 
step 210, and at step 212 the process loops back to 
step 206 for the next line or map of the sorted list. 
The process continues to iterate through steps 206- 
212 until all lines are generated representing the 

25 modifications between the old and new directories. 
At step 214, the mapping code is then wrapped into 
the argument parser and the routines are output to 
generate software tool 216, ending this part of the 
process at step 218. 
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While the processes of generating the 
mapping file (FIG. 1) and developing the migration 
tool (FIG. 2) are described as separate processes, it 
may be desirable to combine the processes and 
5 generate the mapping file as part of the development 
of the migration software tool. 

The software tool created at step 216 is 
then tested for functionality and packaged with the 
ASIC design system whose directory structure was 
10 input at step 102. The package is then supplied to 
the user. 

FIGS. 3A and 3B, taken together, illustrate 
the process performed by a computer under control of 
the software tool operated by the user to migrate 

15 user files from the previous or original ASIC design 
system to the new ASIC design system. At step 300, 
the user design files are input to the computer that 
contains the tool generated in FIG . 2 . At step 302 , 
the arguments are parsed, requiring a minimum of one 

20 input file, and control flags are set based on the 
requirements of the user. For example, a "DIRONLY" 
flag is set so only directory names are changed. If 
the DIRONLY flag is not set, library names will be 
changed without regard to the context in which they 

25 appear. A "STDOUT" flag indicates a standard system 
output for the migration file will be generated, and 
a "NOBAK" flag indicates that back-up of the original 
file is not to be retained. The setting or not 
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setting of these flags by the user establishes the 
nature of the output files. 

At step 304 , an iterative process is 
performed on each input file. More particularly, at 
5 step 306, one of the input files is opened and a 
temporary file output is established. At step 308, 
an iterative process is performed on each line of the 
selected input f ile . This process commences with an 
iterative process at step 310 on each source 

10 directory within each line of each input file. More 
particularly, at step 312, the computer determines 
whether the line opened at the current iteration of 
step 308 references the source directory identified 
at step 310. If it does, the process continues to 

15 step 314 where the computer creates a map that 
identifies changed directory references in the line, 
based on the changes identified in the software tool 
corresponding to the referenced source name. The 
directory reference in the computer file is updated 

20 at step 316 based on the map from tool 216. At step 
318 the next source directory is obtained, and the 
process loops back to step 312 for the next source 
directory. If, at step 312, the line does not 
reference the source directory, the process simply 

25 skips to step 318 for the next source directory. The 
process continues through the iterations of step 310 
until all of the source directories of the line are 
updated, whereupon the process continues to step 320. 
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At step 320, if the STDOUT flag is set, the 
standard operating system file handle output is 
provided for the referenced source directory. If it 
is not set, at step 322 the line established by 
5 iterative process 310 is forwarded to the temporary 
output file opened at step 306, and at step 324 the 
process loops back to the beginning of process 306 
for the next line of the input file. 

The process continues to iterate through 

10 steps 308 and 310 until all of the source directories 
in each line of the input file have been updated. 
The process then continues to step 326 where the 
NOBAK flag is examined to determine whether the user 
desires to retain the original file as a back-up. By 

15 default, a backup file (extension ".bak") will be 
created that has the unmodified contents of the 
original file. If the original is to be retained as 
a back-up file, the original file is moved to a back- 
up file at step 328 and the temp file is closed at 

20 step 330. The updated temp file is then renamed as 
the new original file at step 332. If, at step 326, 
a back-up was not desired to be retained, then the 
temp file becomes the original file at step 322 
without backing up through steps 328 and 330. 

25 After moving the temp file to the original 

file, the next file is obtained at step 334, and the 
process loops back to step 306 where the selected 
next file and the temp output file is opened. The 
process continues to iterate through steps 304, 308 
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and 310 until each source directory in each line of 
each input file is updated, thereby completing the 
migration of the input files from the previous 
directory structure to the new directory structure, 
5 and the process ends at step 336. 

Each input file that contains a reference 
to a directory path in the previous design system is 
modified to reference directory paths in the new or 
updated design system. More particularly, the 

10 software tool identifies directory names in the user 

S3 script to modify the corresponding path references. 

In some cases, directories may be consolidated in the 

^ new design system. Consequently, some directories 

may have multiple references in the output of the 

fj! 15 modified script as the result of this consolidation. 

s Most EDA tools can accept reference to the same 

Q directory more than once, although the tool may issue 

W warnings of multiple path references. 

g The tool according to the present invention 

f ^ 2 0 permits automation of customer migration to new 

design kits and provides the customer with the 
ability to automatically migrate data files with 
directory references without manual file edits. 
Consequently, ASIC vendor design teams can make 
25 design system library changes with minimal effort of 
implementation, and the need to document changes to 
the directory structure is minimized. The migration 
tool is generated by the ASIC vendor, thereby 
increasing reliability and consistent performance of 
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the portion executed by customers . Errors in 

implementing file changes are minimized, and customer 
time and resources for maintenance and upgrade of 
local files is minimized. 
5 The tool also provides the framework to 

support future design system updates. More 
particularly, ASIC developers may create design 
systems following conventions established by the 
software tool, thereby aiding in migration of user 
10 computer files to and through subsequent future 
updates . 

While present embodiments contemplate 
automated development of the migration tool through 
the process of FIGS. 1 and 2, it would be possible to 

15 develop the software tool manually. This approach 
would have the disadvantage of increased likelihood 
of errors and support issues versus the automation 
implemented by this invention. Dropping the 

automated tool development also would create 

20 redundant development effort and therefore require 
more effort by the ASIC vendor to develop and 
maintain the customer executed converter over several 
design system releases. 

Although the present invention has been 

25 described with reference to preferred embodiments, 
workers skilled in the art will recognize that 
changes may be made in form and detail without 
departing from the spirit and scope of the invention. 



